昨天把三台機器擺在同一顆模型前面，量出來的是 tok/s。但提案會議上沒人問 tok/s，他們問的是另一句——

「所以，這台機器能同時服務幾個人？」

這句話有三種答案，混在一起講是地端提案最常見的死法。今天先把三個「人數」拆開，再用一條 1961 年就證完的排隊公式串回來，最後發一張七檔速查表。

三種「人數」：工程師、SRE、老闆講的不是同一件事

第一種是 KV 容得下幾條：這一刻能同時常駐在 KV cache 裡的序列數，上限 ＝ KV 預算 ÷ 每序列 KV，Day 09 的公式算的就是它。注意它不是固定的 slot 數：vLLM 按 block 隨用隨配，而吃 KV 的是 prompt 加上已生成的 token，實際序列短一點就裝得下更多。這是工程師的數字。

第二種是在途請求（in-flight）：正在生成、或還在排隊等生成的請求數。它可以遠大於常駐條數，代價是排隊時間全灌進 TTFT。這是 SRE 的數字。

第三種是尖峰活躍使用者：業務口中的「尖峰同時有多少人在用」。這些人大部分時間在讀答案、想問題、打字，不佔 GPU。這是老闆的數字。

圖 1：每往上一層單位就換一次，而提案裡通常只寫一個數字。

混談的代價，一筆公開量測就夠。CloudRift 貼出一份 raw 輸出：Llama-3.3-70B AWQ-INT4，400 併發打進去，1,200 個請求全數成功，output 吞吐 1,223 tok/s。

接得下。但同一份輸出裡 mean TTFT 是 158 秒、median 166 秒、P99 273 秒——一半的請求等超過兩分半，才收到第一個 token。

接得下，不代表服務得好。把在途請求當成服務人數寫進提案，上線那天就是 Day 01 那場 45 秒事故的三倍半。

條件：Meta-Llama-3.3-70B-Instruct-AWQ-INT4、vLLM（版本未載明）、--max-model-len 8192 --kv-cache-dtype fp8、input／output 各 1,000 token、1,200 requests、400 併發、4 張 GPU（兩份 PP2 replica 掛 NGINX，是 PP 不是 TP）。頁面沒在該區塊標卡型，此處只引 latency 形狀，不做跨硬體比較。來源：cloudrift.ai/blog/benchmarking-rtx-gpus-for-llm-inference

Little 定律：量到 req/s 之後，怎麼換成人數？

換成使用者語言，公式只有一條（Little 定律 1961 年就證完的那個，用在互動系統上叫 Interactive Response Time Law）：

N ＝ X × (R ＋ Z)
  N 活躍使用者   X 滿足 SLO 時可持續的 req/s(goodput)
  R 一次問答的完整回應時間(含 TTFT)   Z 讀答案、想問題、打字的時間

問題只有一個：**X 從哪來？**我原本想從 KV 容量倒推，用 T2 那張 12 GiB 卡：

❌ 錯誤示範

@8K 的 KV 容量上限        4 條
400 token ÷ 20 tok/s      20 秒
一個人 60 秒問一輪
→ 4 ÷ 20 × 60           = 12 人

錯在我偷偷把 C 當成了 X：KV 能同時放 4 條，不代表每 20 秒就能完成 4 個請求。而且那個 4 本身也不是固定值——

同一份 4.93 GiB 的 KV 預算,同一顆 8B(128 KiB/token)
  每條吃滿 8K   → 每序列 1,024 MiB → 4 條
  每條 1,024 in + 256 out → 每序列 160 MiB → 31 條

4 當保守上限帳有意義，但拿去代表 1.3K 的實際 workload 會低估八倍。

圖 2：「4」不是硬體規格，是「假設每條都吃滿 8K」這個前提算出來的。

我也不能拿 Day 03 那個 5.8 秒去估 X：那是另一台機器、另一個 backend、另一組 workload（T1／Metal／Q4_K_M／256 token，對上這裡的 T2／vLLM／AWQ／400 token）。Day 19 雖然會掃 rate，條件同樣不同。

C 算得出來，X 給不出來——要拿到今天的 X，還欠一輪同 workload 的 rate sweep。

七檔容量速查表：從 8GB 消費卡到 4× H100

規則先立好：這張表只有容量線。「塞不塞得下、能常駐幾條」是架構層的 paper sizing，可以同表比較（實際 allocation 仍受各家 runtime 的 padding 影響）；吞吐數字一格都不放，那是另一條線、另一種量法，跨後端不能直比（Day 03、Day 08 立過的規矩）。

KV 預算  ≈ 可用記憶體 − 權重 − 非 KV 開銷
@8K 容量 ≈ KV 預算 ÷ 每序列(KV cache + 固定 state)

分母可以心算：@8K 時 1 KiB/token 剛好等於 8 MiB／序列，context 換一半就把 8 換成 4。hybrid、sliding、MLA 的固定 state 已經算進表裡。這是 paper sizing，實機以 runtime 印出的 KV capacity 為準。

表內 KV 一律按 FP16；模型名稱裡的 FP8／Q4／MXFP4 指的是權重格式，不是 KV。權重取實際量化檔、架構取官方 config.json；顯卡規格是二進位 GiB、權重檔是十進位 GB，相減前先換算（Day 07 的規矩）。消費卡四格沿用 Day 03 的記憶體口徑，T3／T4 沿用 Day 09（非 KV 開銷 3 GB 是每張卡，T4 那格扣了四份）；hybrid state、FP8 換算與逐格驗算都在 Day 09 那支計算機。這張表看量級，別把個位數當承諾——overhead 多抓 0.4 GB，16 GiB 那格就從 5 掉到 3。

※ 本表同步更正過往 gpt-oss-20b 的權重（day04／day06 記 12.1 GB、day11 記 13 GB，實為 13.76 GB ＝ 12.82 GiB）與 T4 的 TP 拓樸口徑（Day 09 走 2×TP2，本表走 TP4 單副本）。

**第一課：容量不是服務能力。**T1 紙上放得下 26 條，但它跑 70B 的單流 decode 只有個位數 tok/s。128GB 決定容量，546 GB/s 則是 memory-bound decode 的頻寬天花板——兩條線單位不同（條 vs req/s），不能互換，更不能取 min。（Metal 的批次聚合能疊到多高，本系列還沒量，標【待實測】。）

**第二課：模型比卡大小更重要。**同一張 24 GiB 卡，gpt-oss-20b 是 43 條、Qwen3.8-27B 是 8 條、Qwen3.6-35B-A3B（UD-Q4_K_M 22.13 GB）只剩 1 條——最後這顆的權重吃掉 95% 的預算，而 Day 06 把它跟 24–32GB 列在同一格。**權重放得下，不等於服務得了。**看的是「剩餘 VRAM ÷ 每序列 KV」，不是 B 數。

圖 3：兩個地方都會咬人——權重吃掉多少預算，每序列又吃掉剩下的多少。

8 GiB 那格歸零也是同一件事：Gemma 4 的 KV/token 全表最省、權重也進得去，卡住它的是 320 MiB／序列的封頂 state。

**第三課：大模型不一定更吃 KV。**gpt-oss-120b 在 96 GiB 上還留得下 86 條 @8K，Llama-3.3-70B 只有 18 條。差距主要來自 attention 結構——18 層全注意力 × head_dim 64，對上 70B 的 80 層 × 128——不是 MoE。MoE 的好處在另一邊：總參數比 70B 多七成，每 token 只啟用約 5.1B。

這張表的算術 Day 09 那支計算機都按得出來（網址在 Day 09 文末），但它預設走機房那本帳，要對上消費卡四格得自己把係數換成 0.9／0.6 GB／FP16。

業界視角：sizing 按尖峰，不按平均

真正做 sizing，我只守三條：按尖峰估、留 KV 餘裕、提案不寫裸併發。

尖峰常是日均的 2–3 倍，但那是經驗係數不是量測值，換一個人數整組跟著換。KV 壓力過高時可能觸發 preemption，體感是串流停一下再接下去；我習慣留 20–30% headroom，那是我的習慣，不是 vLLM 官方標準（Day 19 會讓你看到不留的下場）。

至於尖峰是幾個人，今天故意不填——**在 X 還沒實測之前，任何「這張卡養得起幾十人」都只是把假設包裝成答案。**規格該寫成「p95 TTFT 低於 2 秒、每人至少 20 tok/s 之下，尖峰活躍使用者 N 人」，而 N 要從實測的 X 換算。

今天的實驗需要什麼

紙筆就夠：照上表算出自己那台的 C。想往下走一步的，用 Day 03 的 vllm bench serve 獨立掃一次 request-rate，找出 TTFT 與 TPOT 開始讓 SLO 失守的那一格——那就是 X。

小結

• **只記一條鏈：KV 容量 C 用算的 → SLO goodput X 用量的 → N ＝ X(R＋Z) 才換成人數。**所以「400 併發」與「KV 塞得下 43 條」，都不是 400／43 個使用者。
• 「4 條」是每條按 8K 計的保守假設，同一份預算在 1.3K 的實際序列下裝得下 31 條——表頭那個 @8K，決定了整格的答案。
• **C 是記憶體問題，X 是服務能力問題，N 才是老闆的問題。**三者差一個量級，報告先聲明講的是哪一種。

第二張地圖走完了：裝不裝得下，紙筆算得出來；能服務幾個人，紙筆只能算最後一哩。中間那個 X，還是得讓機器自己回答。明天進 W3：Day 15〈五顆 2026 模型解剖〉，從 Kimi K3 與 GLM-5.2 開始拆——架構的每一個選擇，怎麼決定你在 W1、W2 量到的每一個數字。

咱們明天見。